最新更新內容於 Blog
至從吉米跟 Eric 請益完 git flow 後，時間又過去一個多月。
這天，Eric 與吉米一同參加同一場技術分享會。兩人在會中休息時，Eric問起了吉米的近況。
Eric: 版控使用上，還習慣嗎？有沒有遇到什麼問題？
吉米: 還行。不過，確實有遇到一些小問題。像我把變更後的資料，push 到 remote repository 。到了另一台電腦 pull 下來後，發現程式無法 build。原因是 在 push 時，遺漏檔案 或 兩台電腦的環境不同，程式專案的組態設定無法直接使用。
Eric: 這些問題是不難解決，但確實很煩人。看起來，我們可以接著往 CI/CD 的方向進行。那這些問題，就不會再發生了。
吉米: 還記得之前在介紹 BitBucket、Azure DevOps 時，也有提到 CI/CD。只知道是一種自動化的環境，但不是很清楚了解它的作用。
Eric: 哈哈，我簡單說明一下。
Clone 的專案無法執行
A 將手上可以正式執行與建置的專案，提交到版本控制系統。但因為 A 的粗心，少提交相關的檔案，或組態設定內的設定指向不在版管範圍內的檔案。
當 B 接手維護時，因為檔案缺少或組態設定錯誤，造成 B 要花費額外的時間進行修正。
提交程式碼時，發現大量的衝突，需花大量額外時間來解決衝突
A、B、C 三位開發者協力開發一個系統，若三人都在負責功能開發完成後，才提交修改內容。
第一個提交的人很幸運，可能沒有任何的衝突。
第二個提交的人，因為手上的版本與線上的版本，己經有相當大的差異，他可能要額外花時間解決與前一位提交者的衝突。
第三個提交旳人，就更辛苦。因為最新版本的程式，在經過兩位提交的變更後，版本間的差異更大。變動的範圍越大，可能衝突項目就更多。甚至可能會重覆出現第二位提交者所遇到的衝突。
(圖片來源: Cisco Blogs)
常從其他人口中，將 CI/CD 混在一起說，但其實 CI/CD 分別指 持續整合(Continuous Integration, CI)、持續部署inuous Delivery, CD)、持續交付(Continuous Deployment, CD)，後者負責範圍包括前者的內容。
在筆者看來，CI/CD 比較像是三個不同階段的任務，只有完成了前一個階段，才能進入下一個階段。
曾經團隊協同開發過的人，應該都有遇到在提交時，為了解決程式碼衝突，結果花上更多的時間在處理衝突的程式碼。
尤其提交間隔越久的開發者，處理程式碼的衝突，就越困難。而且還可能造成團隊的成員重複解決相同程式區塊的衝突。整合的時間越晚，整合的難度與失敗的機率就越高。
持續整合的目的，利用頻繁地提交新功能的變更，觸發自動化建置和測試，確保最新版本的軟體是可運行的。
完成整合的階段後，接下來就是部署的階段。
不管是為了測試、驗收或上線，都一定需要進行軟體的部置。但是往往部署環境的差異，造成驗收或上線時的兵荒馬亂。
持續部署的目的，就是要快速而自動的部署，任何版本的軟體到不同的環境。為此，須採用同一個包裝好的套件 (package)，以達到 簡化組態管理(configuration management) 與 減少部署所需的時間。
另外，因為採用同一 package 進行部署的因素，必需將其組態 / 設定外部化 (configuraiton externalization)。簡單點講，就是不要將設定寫死 (hard-coded) 在程式碼。
持續交付的目標，就是 儘快將最新版本的軟體，交付到最終使用者(end-user)手中。
為達到持續交付，必需先行建立 持續整合 跟 持續部署 的機制。
持續整合是 CI/CD 最重要的一點，如果提交的程式有問題，造成整合失敗。對於發生失敗的這種情況，團隊內的成員，需要在一開始就要溝通清楚，取得共識。
對於上面提到，提交造成整合失敗的情況，常見的做法有……
持續整合需要團隊內，所有成員的一同努力與堅持，才能達到良好的效果。
Eric: 剛剛只是介紹完 持續整合、持續部置到持續交付 的觀念。但 CI/CD 環境的架設，一口氣到位的難度頗高。一步一步的架設，會比較安穩。
吉米: 確實，因為現在版控的條件己經滿足了，那下一步就是架設 自動建置 的環境。
Eric: 沒錯。不過，晚點我有一些事情要先離開處理。我們再約個時間，針對自動建置的架設，進一步的討論。
吉米: 好，時間再跟你約。
<< 待續 >>
你好~
持續部署的英文應該是Continuous Deployment
持續交付的英文應該是Continuous Delivery
可以確認一下喔
謝謝提醒
iThome鐵人賽
看影片追技術